Conventional circuit simulators provide SPICE (Simulation Program with Integrated Circuit Emphasis) device models to perform various AC (alternating current), DC (direct current), RF (radio frequency), noise, and/or transient analyses for electronic designs, especially nonlinear electronic designs. These conventional circuit simulators accept a textual input such as a textual netlist in which connectivity among instances, nets, nodes, etc. of the electronic design of interest is specified using, for example, the ASCII (American Standard Code for Information Interchange) format (e.g., a Standard Parasitic Exchange Format or SPEF file) or textual format (e.g., a textual netlist).
Design data of modern electronic designs are often stored in a hierarchical data structure such as a schematic database and a layout database to facilitate the ease and efficiency of manipulating and processing design data, especially in view of the more complex electronic designs having more hierarchies. Moreover, modern EDA (electronic design automation) tools automatically instantiate parameterized models or cells where different parameter values corresponding to different variants of structures of a parameterized model have become more popular to simplify the design process. Parameterized models or cells are often coded in C++ language and compiled into object files. In conventional approaches, the structures of variants of a parameterized model are nevertheless directly specified in the textual input with their corresponding values. Due to high complexities and hence smaller margins for errors in modern electronic designs, parasitic information (e.g., resistance R, capacitance C, and/or inductance L) may affect the performance and/or reliability of an electronic design and is thus often included in various analyses to ensure that the electronic design, when manufactured, meets various performance and reliability goals.
In a conventional simulation flow such as the one illustrated in FIG. 1A, a netlister 104 receives and parses the layout database 102 to generate a textual netlist 106. For simulation purposes, the netlist is forwarded to the parser 108 through a frontend of a simulator. A simulation database is then formed with the information from the netlist 106 and subsequently used as an input 112 for the simulation engines. In other words, the original layout data in a database format is first translated or transformed into a textual netlist which is subsequently processed back into a database format—the simulation database. In addition to multiple transformations of design data among different formats, a textual netlist is well known to be difficult for partitioning (e.g., identifying the boundaries between an analog portion and a digital portion in a mixed-signal design). The difficulties in partitioning a textual netlist are further exacerbated in the parallel and distributed simulation paradigms and may affect load-balancing and the overall runtime of various computing nodes.
To accommodate the parasitics, a parasitic extractor 110 may extract the parasitic information from the layout database 102 to generate the required or desired parasitic information in a format such as an SPEF (Standard Parasitic Exchange Format), a DSPF (Detailed Standard Parasitic Format), or a DPF (Dynamic Process Format) parasitic file. The parasitic information in the parasitic file 114 needs to be stitched into the appropriate locations of the simulation database 112 using a parasitic stitcher 114 in the simulation platform. Such a stitching process is generally known to be error prone due to the requirement to identify the correct locations to insert or annotate the appropriate parasitic information or device. Once the stitching of parasitic information is done, the simulator 116 (e.g., a SPICE-like simulator) may then simulate the electronic design of interest with the simulation database 112.
With the textual input 112, the layout 102 and the simulator 116 are disconnected in the sense that any layout changes cannot be reflected in the analysis input without proceeding through various transformations from the layout database to the textual netlist and the textual parasitic files as well as the stitching processing, and that any findings from the simulation results cannot be effectively reflected in the layout database without proceeding through the reverse processes of the aforementioned transformations and stitching.
Therefore, there exists a need for methods, systems, and computer program products for implementing a simulation platform with dynamic device model libraries for electronic designs.